The present invention relates to technology of enhancing the efficiency of appliance networks, and more particularly, to a negotiation apparatus and computer program product for processing incoming transactions based on resource utilization status of backend systems in an appliance cluster.
As the Internet advances, ever-increasing information services are offered to users. The users expect a certain degree of quality of the information services in terms of response time and throughput (TPS), etc. As soon as the thresholds of specified (monitored) indicators are reached, the infrastructure of information services must provide a mechanism for measuring the current status and giving an appropriate response to ensure the service quality anticipated by the users.
In practice, to maintain high availability of services, enterprises or organizations nowadays duplicate the same system in different areas to allow network engineers to achieve disaster recovery in the shortest possible time. High availability is an important dimension of the disposition of multiple appliances which form a cluster, especially appliance products of the processing units owned by enterprises and disposed in a demilitarized zone (DMZ).
To make good use of available resources, enterprises usually use (active/active) high availability architecture whereby systems at different locations can support each other. In practice, an appliance that serves as a reverse proxy is disposed at every location in the DMZ to protect backend systems, i.e., the intranet resources 107. The reverse proxy controls traffic by well-known service level monitoring (SLM) to prevent the backend systems from being overwhelmed by unanticipated burst messages. Examples of the messages include a packet, a transmission control protocol (TCP) stream, and a transaction.
Service level monitoring (SLM) technology usually requires enforcing an SLM policy or regulations to monitor specified indicators and assist a network administrator in identifying a problem instantly and making an appropriate response. The specified indicators are, for example, specific headers of messages received. For instance, HTTP, MQ or FTP packets each carry a unique specific header for identification. According to the prior art, during its operation, an SLM module of an appliance not only monitors the number of incoming messages which carry a specific header and are received by the appliance but also sanctions the way of processing the messages according to the real-time SLM status. For instance, when the number reaches a specified threshold, the reverse proxy performs a specified operation pursuant to the SLM policy. The specified operation is queue (or paraphrased as “shape”), reject (or paraphrased as “throttle”), or pass (or paraphrased as “notify”).
However, the SLM policy is basically fixed (such as a fixed threshold) and thus cannot be adjusted. In particular, the SLM policy cannot be adjusted according to the load of all intranet resources of backend systems. If the load of a specific server in backend systems is saturated and the incoming transaction (or message) rate of all the intranet resources is still below a predetermined threshold, the newly received incoming transaction (or message) will still pass the SLM policy and thus cause a specific server in the backend systems to crash, that is, the system will no longer be functional. The incoming transaction rate is also referred to as traffic injection rate. Furthermore, from the perspective of multiple reverse proxies at different positions, there is not any mechanism for switching traffic statuses to optimize the access of available resources at different positions. Due to the lack of load information of backend systems and status information of appliances at different positions in global area, the appliances (reverse proxies) in the DMZ cannot access available resources at different positions.